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Abstract 

The monoid is a humble algebraic structure, at first glance even 
downright boring. However, there's much more to monoids than 
meets the eye. Using examples taken from the diagrams vector 
graphics framework as a case study, I demonstrate the power and 
beauty of monoids for library design. The paper begins with an 
extremely simple model of diagrams and proceeds through a series 
of incremental variations, all related somehow to the central theme 
of monoids. Along the way, I illustrate the power of compositional 
semantics; why you should also pay attention to the monoid's 
even humbler cousin, the semigroup; monoid homomorphisms; and 
monoid actions. 

Categories and Subject Descriptors D.l.l [Programming Tech- 
niques]: Applicative (Functional) Programming; D.2.2 [Design 
Tools and Techniques] 

General Terms Languages, Design 

Keywords monoid, homomorphism, monoid action, EDSL 

Prelude 

diagrams is a framework and embedded domain-specific language 
for creating vector graphics in Haskell. 1 All the illustrations in 
this paper were produced using diagrams, and all the examples 
inspired by it. However, this paper is not really about diagrams 
at all! It is really about monoids, and the powerful role they — and, 
more generally, any mathematical abstraction — can play in library 
design. Although diagrams is used as a specific case study, the 
central ideas are applicable in many contexts. 

Theme 

What is a diagram! Although there are many possible answers to 
this question (examples include those of Elliott [2003] and Matlage 
and Gill [2011]), the particular semantics chosen by diagrams is 
an ordered collection of primitives. To record this idea as Haskell 
code, one might write: 

type Diagram = [Prim] 

But what is a primitive! For the purposes of this paper, it doesn't 
matter. A primitive is a thing that Can Be Drawn — like a circle, arc, 
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Figure 1. Superimposing a list of primitives 



polygon, Bezier curve, and so on — and inherently possesses any 
attributes we might care about, such as color, size, and location. 

The primitives are ordered because we need to know which 
should appear "on top". Concretely, the list represents the order 
in which the primitives should be drawn, beginning with the "bot- 
tommost" and ending with the "topmost" (see Figure 1). 

Lists support concatenation, and "concatenating" two Diagrams 
also makes good sense: concatenation of lists of primitives corre- 
sponds to superposition of diagrams — that is, placing one diagram 
on top of another. The empty list is an identity element for con- 
catenation ([] -\+xs = xs-\+ [] = xs), and this makes sense in the 
context of diagrams as well: the empty list of primitives represents 
the empty diagram, which is an identity element for superposition. 
List concatenation is associative; diagram A on top of (diagram B 
on top of C) is the same as (A on top of B) on top of C. In short, 
(+f) and [] constitute a monoid structure on lists, and hence on 
diagrams as well. 

This is an extremely simple representation of diagrams, but it 
already illustrates why monoids are so fundamentally important: 
composition is at the heart of diagrams — and, indeed, of many 
libraries. Putting one diagram on top of another may not seem very 
expressive, but it is the fundamental operation out of which all other 
modes of composition can be built. 

However, this really is an extremely simple representation 
of diagrams — much too simple! The rest of this paper develops 
a series of increasingly sophisticated variant representations for 
Diagram, each using a key idea somehow centered on the theme of 
monoids. But first, we must take a step backwards and develop this 
underlying theme itself. 

Interlude 

The following discussion of monoids — and the rest of the paper in 
general — relies on two simplifying assumptions: 



• all values are finite and total; 

• the floating-point type Double is a well-behaved representation 
of the real numbers R. 

The first assumption is reasonable, since we will have no need for 
infinite data structures, nontermination, or partial functions. The 
second is downright laughable, but makes up for in convenience 
what it lacks in accuracy. 

Monoids 

A monoid is a set 5 along with a binary operation o :: 5 — > S -¥ 5 
and a distinguished element e :: 5, subject to the laws 

eox = xoe = x (Ml) 
xo(yoz) = (xoy)oz. (M2) 

where x, y, and z are arbitrary elements of 5. That is, e is an identity 
for o (Ml), which is required to be associative (M2). 

Monoids are represented in Haskell by the Monoid type class 
defined in the Data. Monoid module, which is part of the standard 
base package. 

class Monoid a where 

e ::a 

(o) ::a — > a — > a 

mconcat:: [a] — >• a 
mconcat =foldr (o) e 

The actual Monoid methods are named mempty and mappend, but 
I will use e and (o) in the interest of brevity. 
mconcat "reduces" a list using (o), that is, 

mconcat [a,b,c,d] = ao(bo(cod)). 

It is included in the Monoid class in case some instances can 
override the default implementation with a more efficient one. 

At first, monoids may seem like too simple of an abstraction 
to be of much use, but associativity is powerful: applications of 
mconcat can be easily parallelized [Cole 1995], recomputed in- 
crementally [Piponi 2009], or cached [Hinze and Paterson 2006]. 
Moreover, monoids are ubiquitous — here are just a few examples: 

• As mentioned previously, lists form a monoid with concatena- 
tion as the binary operation and the empty list as the identity. 

• The natural numbers N form a monoid under both addition 
(with 0 as identity) and multiplication (with 1 as identity). The 
integers Z, rationals Q, real numbers E, and complex numbers 
C all do as well. Data. Monoid provides the Sum and Product 
newtype wrappers to represent these instances. 

• N also forms a monoid under max with 0 as the identity. How- 
ever, it does not form a monoid under min; no matter what neN 
we pick, we always have min(n,n + 1) = n ^ n + 1, so n can- 
not be the identity element. More intuitively, an identity for min 
would have to be "the largest natural number", which of course 
does not exist. Likewise, none of Z, Q, and E form monoids 
under min or max (and min and max are not even well-defined 
onC). 

• The set of booleans forms a monoid under conjunction (with 
identity True), disjunction (with identity False) and exclusive 
disjunction (again, with identity False). Data. Monoid provides 
the All and Any newtype wrappers for the first two instances. 

• Sets, as defined in the standard Data. Set module, form a 
monoid under set union, with the empty set as the identity. 

• Given Monoid instances for m and n, their product (m, n) is also 
a monoid, with the operations defined elementwise: 



instance (Monoid m, Monoid n) 
=> Monoid (m,n) where 
e =(£,£) 
(mi,ni)o (m2,«2) = (m\Om2,n\ 0/12) 

• A function type with a monoidal result type is also a monoid, 
with the results of functions combined pointwise: 

instance Monoid m => Monoid (a — > m) where 

e = const e 

f\ofl =Xa-tf\ aof 2 a 

In fact, if you squint and think of the function type a — > m 
as an "a-indexed product" of m values, you can see this as a 
generalization of the instance for binary products. Both this and 
the binary product instance will play important roles later. 

• Endofunctions, that is, functions a — > a from some type to itself, 
form a monoid under function composition, with the identity 
function as the identity element. This instance is provided by 
the Endo newtype wrapper. 

• The dual of any monoid is also a monoid: 

newtype Dual a = Dual a 

instance Monoid a => Monoid (Dual a) where 
e = Dual e 

(Dualmi)o(Dualm2) = Dual (miom\) 

In words, given a monoid on a, Dual a is the monoid which uses 
the same binary operation as a, but with the order of arguments 
switched. 

Finally, a monoid is commutative if the additional law 

xoy — yox 

holds for all x and y. The reader can verify how commutativity 
applies to the foregoing examples: Sum, Product, Any, and All 
are commutative (as are the max and min operations); lists and 
endofunctions are not; applications of (,), ((—>■) e), and Dual are 
commutative if and only if their arguments are. 

Monoid homomorphisms 

A monoid homomorphism is a function from one monoidal type 
to another which preserves monoid structure; that is, a function / 
satisfying the laws 

fe = e (HI) 

f(xoy)=fxofy (H2) 

For example, length [] = 0 and length (xs 4+y.s) = length xs + 
length ys, making length a monoid homomorphism from the 
monoid of lists to the monoid of natural numbers under addition. 

Free monoids 

Lists come up often when discussing monoids, and this is no ac- 
cident: lists are the "most fundamental" Monoid instance, in the 
precise sense that the list type [a] represents the free monoid over 
a. Intuitively, this means that [a] is the result of turning a into a 
monoid while "retaining as much information as possible". More 
formally, this means that any function / :: a — > m, where m is a 
monoid, extends uniquely to a monoid homomorphism from [a] 
to m — namely, mconcat o map f. It will be useful later to give this 
construction a name: 

horn:: Monoid m => (a -¥ m) -¥ ([a] -¥ m) 
horn f = mconcat o mapf 

See the Appendix for a proof that homf really is a monoid homo- 
morphism. 



Semigroups 

A semigroup is like a monoid without the requirement of an identity 
element: it consists simply of a set with an associative binary 
operation. 

Semigroups can be represented in Haskell by the Semigroup 
type class, defined in the semigroups package 2 : 

class Semigroup a where 

(o) ::a — > a — > a 

(The Semigroup class also declares two other methods with default 
implementations in terms of (o); however, they are not used in 
this paper.) The behavior of Semigroup and Monoid instances for 
the same type will always coincide in this paper, so using the 
same name for their operations introduces no ambiguity. I will also 
pretend that Monoid has Semigroup as a superclass, although in 
actuality it does not (yet). 

One important family of semigroups which are not monoids are 
unbounded, linearly ordered types (such as Z and E) under the 
operations of min and max. Data. Semigroup defines Min as 

newtype Min a = Min {getMin ::a} 

instance Ord a => Semigroup (Min a) where 
Min no Min b = Min (min a b) 

and Max is defined similarly. 

Of course, any monoid is automatically a semigroup (by for- 
getting about its identity element). In the other direction, to turn a 
semigroup into a monoid, simply add a new distinguished element 
to serve as the identity, and extend the definition of the binary oper- 
ation appropriately. This creates an identity element by definition, 
and it is not hard to see that it preserves associativity. 

In some cases, this new distinguished identity element has a 
clear intuitive interpretation. For example, a distinguished identity 
element added to the semigroup (N,min) can be thought of as 
"positive infinity": min(+°°,n) = min(n,+co) = n for all natural 
numbers n. 

Adding a new distinguished element to a type is typically ac- 
complished by wrapping it in Maybe. One might therefore expect 
to turn an instance of Semigroup into an instance of Monoid by 
wrapping it in Maybe. Sadly, Data. Monoid does not define semi- 
groups, and has a Monoid instance for Maybe which requires a 
Monoid constraint on its argument type: 

instance Monoid a => Monoid (Maybe a) where 
e = Nothing 
Nothingofe = b 

a o Nothing = a 

(Just a) o (Just b) = Just (aob) 

This is somewhat odd: in essence, it ignores the identity ele- 
ment of a and replaces it with a different one. As a workaround, 
the semigroups package defines an Option type, isomorphic to 
Maybe, with a more sensible Monoid instance: 

newtype Option a = Option {getOption :: Maybe a} 
instance Semigroup a => Monoid (Option a) where 

The implementation is essentially the same as that for Maybe, 
but in the case where both arguments are Just, their contents are 
combined according to their Semigroup structure. 

Variation I: Dualizing diagrams 

Recall that since Diagram is (so far) just a list, it has a Monoid 
instance: if d\ and di are diagrams, then d\ o di is the diagram 



containing the primitives from d\ followed by those of di- This 
means that d\ will be drawn first, and hence will appear beneath 
d2- Intuitively, this seems odd; one might expect the diagram which 
comes first to end up on top. 

Let's define a different Monoid instance for Diagram, so that 
d\od2 will result in d\ being on top. First, we must wrap [Prim] in 
a newtype. We also define a few helper functions for dealing with 
the newtype constructor: 

newtype Diagram = Diagram [Prim] 

unD :: Diagram — > [Prim] 
unD (Diagram ps) = ps 

prim :: Prim — > Diagram 
prim p = Diagram [p] 

mkD :: [Prim] — > Diagram 
mkD — Diagram 

And now we must tediously declare a custom Monoid instance: 

instance Monoid Diagram where 

e = Diagram e 

(Diagram ps t )o (Diagram ps 2 ) = Diagram (p.^ops^ 

... or must we? This Monoid instance looks a lot like the instance 
for Dual. In fact, using the GeneralizedNewtypeDeriving ex- 
tension along with Dual, we can define Diagram so that we get the 
Monoid instance for free again: 

newtype Diagram = Diagram (Dual [Prim]) 
deriving (Semigroup, Monoid) 

unD (Diagram (Dual ps)) = ps 

primp — Diagram (Dual [p]) 

mkD ps = Diagram (Dual ps) 

The Monoid instance for Dual [Prim] has exactly the semantics we 
want; GHC will create a Monoid instance for Diagram from the 
instance for Dual [Prim] by wrapping and unwrapping Diagram 
constructors appropriately. 

There are drawbacks to this solution, of course: to do anything 
with Diagram one must now wrap and unwrap both Diagram and 
Dual constructors. However, there are tools to make this some- 
what less tedious (such as the newtype package 3 ). In any case, 
the Diagram constructor probably shouldn't be directly exposed to 
users anyway. The added complexity of using Dual will be hid- 
den in the implementation of a handful of primitive operations on 
Diagrams. 

As for benefits, we have a concise, type-directed specification 
of the monoidal semantics of Diagram. Some of the responsibility 
for writing code is shifted onto the compiler, which cuts down on 
potential sources of error. And although this particular example is 
simple, working with structurally derived Semigroup and Monoid 
instances can be an important aid in understanding more complex 
situations, as we'll see in the next variation. 

Variation II: Envelopes 

Stacking diagrams via (o) is a good start, but it's not hard to imag- 
ine other modes of composition. For example, consider placing two 
diagrams "beside" one another, as illustrated in Figure 2. 

It is not immediately obvious how this is to be implemented. We 
evidently need to compute some kind of bounding information for 
a diagram to decide how it should be positioned relative to others. 
An idea that first suggests itself is to use bounding boxes — that 
is, axis-aligned rectangles which completely enclose a diagram. 
However, bounding boxes don't play well with rotation (if you 
rotate a bounding box by 45 degrees, which bounding box do you 



2 http : //hackage . haskell . org/package/semigroups 



3 http : //hackage .haskell . org/package/newtype 




Figure 2. Placing two diagrams beside one another 




Figure 3. Envelope for an ellipse 



get as a result?), and they introduce an inherent left-right-up-down 
bias — which, though it may be appropriate for something like TgX, 
is best avoided in a general-purpose drawing library. 

An elegant functional solution is something I term an enveloped 
Assume there is a type V2 representing two-dimensional vectors 
(and a type P2 representing points). Then an envelope is a func- 
tion of type V2 — > K. 5 Given a vector v, it returns the minimum 
distance (expressed as a multiple of v's magnitude) from the ori- 
gin to a separating line perpendicular to v. A separating line is one 
which partitions space into two half-spaces, one (in the direction 
opposite v) containing the entirety of the diagram, and the other (in 
the direction of v) empty. More formally, the envelope yields the 
smallest real number t such that for every point u inside the dia- 
gram, the projection of u (considered as a vector) onto v is equal to 
some scalar multiple sv with s ^ r. 

Figure 3 illustrates an example. Two query vectors emanate 
from the origin; the envelope for the ellipse computes the distances 
to the separating lines shown. Given the envelopes for two dia- 
grams, beside can be implemented by querying the envelopes in 
opposite directions and placing the diagrams on opposite sides of a 
separating line, as illustrated in Figure 4. 

Fundamentally, an envelope represents a convex hull — the locus 
of all segments with endpoints on a diagram's boundary. However, 
the term "convex hull" usually conjures up some sort of intensional 
representation, such as a list of vertices. Envelopes, by contrast, are 
an extensional representation of convex hulls; it is only possible to 
observe examples of their behavior. 



4 The initial idea for envelopes is due to Sebastian Setzer. See http:// 
byorgey . wordpress . com/2009/10/28/collecting-attributes/ 
#comment-2030. 

5 It might seem cleaner to use angles as input to envelopes rather than 
vectors; however, this definition in terms of vectors generalizes cleanly to 
higher-dimensional vector spaces, whereas one in terms of angles would 
not. 




Figure 4. Using envelopes to place diagrams beside one another 




Figure 5. Composing envelopes 



Here's the initial definition of Envelope. Assume there is a way 
to compute an Envelope for any primitive. 

newtype Envelope = Envelope (V2 — > R) 
envelope? :: Prim — > Envelope 

How, now, to compute the Envelope for an entire Diagram? Since 
envelope? can be used to compute an envelope for each of a dia- 
gram's primitives, it makes sense to look for a Monoid structure on 
envelopes. The envelope for a diagram will then be the combination 
of the envelopes for all its primitives. 

So how do Envelopes compose? If one superimposes a diagram 
on top of another and then asks for the distance to a separating line 
in a particular direction, the answer is the maximum of the distances 
for the component diagrams, as illustrated in Figure 5. 

Of course, we must check that this operation is associative 
and has an identity. Instead of trying to check directly, however, 
let's rewrite the definition of Envelope in a way that makes its 
compositional semantics apparent, in the same way we did for 
Diagram using Dual in Variation I. 

Since distances are combined with max, we can use the Max 
wrapper defined in Data . Semigroup: 

newtype Envelope = Envelope (V2 — > MaxM) 
deriving Semigroup 

The Semigroup instance for Envelope is automatically derived 
from the instance for Max together with the instance that lifts 
Semigroup instances over an application of ((— >) V2). The result- 
ing binary operation is exactly the one described above: the input 
vector is passed as an argument to both envelopes and the results 
combined using max. This also constitutes a proof that the oper- 
ation is associative, since we already know that Max satisfies the 
Semigroup law and ((— >) V2) preserves it. 

We can now compute the envelope for almost all diagrams: if 
a diagram contains at least one primitive, apply envelope? to each 
primitive and then combine the resulting envelopes with (o). We 




Figure 6. Negative distance as output of an envelope 



don't yet know what envelope to assign to the empty diagram, but 
if Envelope were also an instance of Monoid then we could, of 
course, use e. 

However, it isn't. The reason has already been explored in the 
Interlude: there is no smallest real number, and hence no identity el- 
ement for the reals under max. If envelopes actually only returned 
positive real numbers, we could use (const 0) as the identity en- 
velope. However, it makes good sense for an envelope to yield a 
negative result, if given as input a vector pointing "away from" the 
diagram; in that case the vector to the separating line is a negative 
multiple of the input vector (see Figure 6). 

Since the problem seems to be that there is no smallest real num- 
ber, the obvious solution is to extend the output type of envelopes 
to RU {— <x>}. This would certainly enable a Monoid instance for 
envelopes; however, it doesn't fit their intended semantics. An en- 
velope must either constantly return — °o for all inputs (if it corre- 
sponds to the empty diagram), or it must return a finite distance for 
all inputs. Intuitively, if there is "something there" at all, then there 
is a separating line in every direction, which will have some finite 
distance from the origin 

(It is worth noting that the question of whether diagrams are 
allowed to have infinite extent in certain directions seems related, 
but is in fact orthogonal. If this was allowed, envelopes could return 
+o° in certain directions, but any valid envelope would still return 
— co for all directions or none.) 

So the obvious "solution" doesn't work, but this "all-or-none" 
aspect of envelopes suggests the correct solution. Simply wrap 
the entire function type in Option, adding a special distinguished 
"empty envelope" besides the usual "finite" envelopes imple- 
mented as functions. Since Envelope was already an instance of 
Semigroup, wrapping it in Option will result in a Monoid. 

newtype Envelope = Envelope (Option (V2 — > Max R)) 
deriving (Semigroup, Monoid) 

Looking at this from a slightly different point of view, the 
most straightforward way to turn a semigroup into a monoid is to 
use Option; the question is where to insert it. The two potential 
solutions discussed above are essentially 

V 2 -> Option (MaxR) 
Option (V 2 ^ MaxR) 

There is nothing inherently unreasonable about either choice; it 
comes down to a question of semantics. 

In any case, the envelope for any diagram can now be computed 
using the Monoid instance for Envelope: 

envelope:: Diagram — > Envelope 
envelope = horn envelopeP o unD 

Recall that horn f = mconcat o map f expresses the lifting of a 
function a — > m to a monoid homomorphism [a] —¥ m. 
If we assume that there is a function 



translateP ::\l 2 — s> Prim — s> Prim 

to translate any primitive by a given vector, we can concretely im- 
plement beside as shown below. Essentially, it computes the dis- 
tance to a separating line for each of the two diagrams (in opposite 
directions) and translates the second diagram by the sum of the 
distances before superimposing them. There is a bit of added com- 
plication due to handling the possibility that one of the diagrams is 
empty, in which case the other is returned unchanged (thus making 
the empty diagram an identity element for beside). Note that the * 
operator multiplies a vector by a scalar. 

translate ::V 2 Diagram — s> Diagram 
translate v = mkD o map (translateP v) o unD 

unE:: Envelope -» Maybe (V 2 -» R) 

unE (Envelope (Option Nothing)) = Nothing 

unE (Envelope (Option (Just/))) = Just (getMaxof) 

beside::V2 ~~ * Diagram — > Diagram — > Diagram 

beside v d\ d 2 = 

case (unE (envelope d\), unE (envelope dj)) of 
(Just ej, Just e 2 ) — > 
d{Otranslate ((e\ v + e 2 (— v))*v) rf 2 

-¥ 

d\_od2 

Variation III: Caching Envelopes 

This method of computing the envelope for a Diagram, while el- 
egant, leaves something to be desired from the standpoint of effi- 
ciency. Using beside to put two diagrams next to each other requires 
computing their envelopes. But placing the resulting combined dia- 
gram beside something else requires recomputing its envelope from 
scratch, leading to duplicated work. 

In an effort to avoid this, we can try caching the envelope, 
storing it alongside the primitives. Using the fact that the product 
of two monoids is a monoid, the compiler can still derive the 
appropriate instances: 

newtype Diagram = Diagram (Dual [Prim], Envelope) 
deriving (Semigroup, Monoid) 

unD (Diagram (Dual /M, _)) =ps 
primp = Diagram (Dual [p], envelopeP p) 
mkD = horn prim 

envelope (Diagram (_,e)) = e 

Now combining two diagrams with (o) will result in their primi- 
tives as well as their cached envelopes being combined. However, 
it's not a priori obvious that this works correctly. We must prove 
that the cached envelopes "stay in sync" with the primitives — in 
particular, that if a diagram containing primitives ps and envelope 
e has been constructed using only the functions provided above, it 
satisfies the invariant 

e = horn envelopeP ps. 

Proof. This is true by definition for a diagram constructed with 
prim. It is also true for the empty diagram: since horn envelopeP 
is a monoid homomorphism, 

horn envelopeP [ ] = £. 

The interesting case is (o). Suppose we have two diagram val- 
ues Diagram (Dual ps\,e\) and Diagram (Dual/»' 2 ,e 2 ) for which 
the invariant holds, and we combine them with (o), resulting in 
Diagram (Dual (ps 2 +\-ps\),e\ oe 2 ). We must show that the in- 
variant is preserved, that is, 

e \ 0 e 2 = horn envelopeP (/« 2 +1- ps\ ) . 



Figure 7. Drawing a line between two shapes 



Again, since horn envelopeP is a monoid homomorphism, 

horn envelopeP (ps2 -H- ps ; ) 

= horn envelopeP psi o horn envelopeP ps^ , 

which by assumption is equal to e2 oe\ . 

But wait a minute, we wanted e\ o ei\ Never fear: Envelope 
actually forms a commutative monoid, which can be seen by noting 
that Max K is a commutative semigroup, and ((->) V2) and Option 
both preserve commutativity. □ 

Intuitively, it is precisely the fact that the old version of envelope 
(defined in terms of horn envelopeP) was a monoid homomorphism 
which allows caching Envelope values. 

Although caching envelopes eliminates some duplicated work, 
it does not, in and of itself, improve the asymptotic time complexity 
of something like repeated application of beside. Querying the 
envelope of a diagram with n primitives still requires evaluating 
Oin) applications of min, the same amount of work as constructing 
the envelope in the first place. However, caching is a prerequisite to 
memoizing envelopes [Michie 1968], which does indeed improve 
efficiency; the details are omitted in the interest of space. 

Variation IV: Traces 

Envelopes enable beside, but they are not particularly useful for 
finding actual points on the boundary of a diagram. For example, 
consider drawing a line between two shapes, as shown in Figure 7. 
In order to do this, one must compute appropriate endpoints for 
the line on the boundaries of the shapes, but having their envelopes 
does not help. As illustrated in Figure 8, envelopes can only give the 
distance to a separating line, which by definition is a conservative 
approximation to the actual distance to a diagram's boundary along 
a given ray. 

Consider instead the notion of a trace. Given a ray specified by 
a starting point and a vector giving its direction, the trace computes 
the distance along the ray to the nearest intersection with a diagram; 
in other words, it implements a ray/object intersection test just like 
those used in a ray tracer. 

newtype Trace = Trace (P2 -¥ V2 — > R) 

The first thing to consider, of course, is how traces combine. Since 
traces yield the distance to the nearest intersection, given two 
superimposed diagrams, their combined trace should return the 
minimum distance given by their individual traces. We record this 
declaratively by refining the definition of Trace to 

newtype Trace = Trace (P2 -¥ V2 -¥ Min R) 
deriving (Semigroup) 

Just as with Envelope, this is a semigroup but not a monoid, since 
there is no largest element of R. Again, inserting Option will make 



Figure 8. Envelopes are not useful for drawing connecting lines! 




+ 00 



Figure 9. Returning +00 from a trace 

it a monoid; but where should the Option go? It seems there are 
three possibilities this time (four, if we consider swapping the order 
of P 2 and V 2 ): 

P 2 ^ V2 -> Option (Min E) 

P 2 -> Option (V 2 -> Min R) 

Option (P 2 ^ V 2 ^ MinR) 

The first represents adjoining +°° to the output type, and the last 
represents creating a special, distinguished "empty trace". The sec- 
ond says that there can be certain points from which the diagram 
is not visible in any direction, while from other points it is not, but 
this doesn't make sense: if a diagram is visible from any point, then 
it will be visible everywhere. Swapping P2 and V2 doesn't help. 

In fact, unlike Envelope, here the first option is best. It is 
sensible to return +00 as the result of a trace, indicating that the 
given ray never intersects the diagram at all (see Figure 9). 

Here, then, is the final definition of Trace: 

newtype Trace = Trace (P2 — > V2 — > Option (Min R)) 
deriving (Semigroup, Monoid) 

Assuming there is a function tracePv. Prim — > Trace to compute 
the trace of any primitive, we could define 

trace:: Diagram — \ Trace 
trace = horn traceP o unD 

However, this is a monoid homomorphism since Trace is also a 
commutative monoid, so we can cache the trace of each diagram as 
well. 

newtype Diagram 

= Diagram (Dual [Prim], Envelope, Trace) 
deriving (Semigroup, Monoid) 



Variation V: Transformations and monoid actions 

Translation was briefly mentioned in Variation II, but it's time to 
consider transforming diagrams more generally. Suppose there is 
a type representing arbitrary affine transformations, and a way to 
apply them to primitives: 

data Transformation = . . . 

transformP :: Transformation — > Prim — > Prim 

Affine transformations include the usual suspects like rotation, re- 
flection, scaling, shearing, and translation; they send parallel lines 
to parallel lines, but do not necessarily preserve angles. However, 
the precise definition — along with the precise implementations of 
Transformation and transformP — is not important for our pur- 
poses. The important fact, of course, is that Transformation is an 
instance of Monoid: t\ oti represents the transformation which per- 
forms first ?2 and then t \ , and £ is the identity transformation. Given 
these intuitive semantics, we expect 

transformP e p = p ( 1 ) 

that is, transforming by the identity transformation has no effect, 
and 

transformP (?i 0*2) P = transformP ty (transformP ti p) (2) 

that is, t\ o t2 really does represent doing first ti and then t\ . (Equa- 
tion (2) should make it clear why composition of Transformations 
is "backwards": for the same reason function composition is "back- 
wards".) Functions satisfying (1) and (2) have a name: transformP 
represents a monoid action of Transformation on Prim. Moreover, 
r\ -reducing (1) and (2) yields 

transformP e = id (1') 
transformP (t\ 0<2) = transformP ty o transformP t2 (2') 

Thus, we can equivalently say that transformP is a monoid homo- 
morphism from Transformation to endofunctions on Prim. 
Let's make a type class to represent monoid actions: 

class Monoid m => Action m a where 

actwm -¥a-¥ a 
instance Action Transformation Prim where 

act = transformP 

(Note that this requires the MultiParamTypeClasses extension.) 
Restating the monoid action laws more generally, for any instance 
of Action m a it should be the case that for all m\,ni2 :: m, 

act£ = id (MAI) 
act (m\ o m-i) = act mi o act m2 (MA2) 

When using these laws in proofs we must be careful to note the 
types at which act is applied. Otherwise we might inadvertently 
use act at types for which no instance of Action exists, or — more 
subtly — circularly apply the laws for the very instance we are 
attempting to prove lawful. I will use the notation A / B to indicate 
an appeal to the monoid action laws for the instance Action A B. 

Now, consider the problem of applying a transformation to an 
entire diagram. For the moment, forget about the Dual wrapper and 
the cached Envelope and Trace, and pretend that a diagram consists 
solely of a list of primitives. The obvious solution, then, is to map 
the transformation over the list of primitives. 

type Diagram = [Prim] 

transformD :: Transformation — > Diagram — > Diagram 

transformD t = map (act t) 

instance Action Transformation Diagram where 

act = transformD 



The Action instance amounts to a claim that transformD satisfies 
the monoid action laws (MAI) and (MA2). The proof makes use 
of the fact that the list type constructor [] is a functor, that is, 
map id = id and map (fog) = map f o map g. 

Proof. 

transformD £ 
= { definition of transformD } 

map (act e) 
= { Transformation / Prim } 

map id 
= { list functor } 

id 

transformD (t\ of 2 ) 
= { definition } 

map (act (t\Ot2)) 
= { Transformation / Prim } 

map (act t\ oactt2) 
= { list functor } 

map (act t\)o map (act t2) 
= { definition } 

transformD t\ o transformD t2 d 

As an aside, note that this proof actually works for any functor, 

so 

instance (Action m a, Functor/) 
=> Action m (f a) where 

act m =fmap (act m) 

always defines a lawful monoid action. 

Variation VI: Monoid-on-monoid action 

The previous variation discussed Transformations and their monoid 
structure. Recall that Diagram itself is also an instance of Monoid. 
How does this relate to the action of Transformation? That is, the 
monoid action laws specify how compositions of transformations 
act on diagrams, but how do transformations act on compositions 
of diagrams? 

Continuing for the moment to think about the stripped-down 
variant Diagram = [Prim], we can see first of all that 

actte = e, (3) 

since mapping t over the empty list of primitives results in the 
empty list again. We also have 

act t (d\od2) = (act t d\) o (act 1 1^) , (4) 

since 

act t (di od2) 
= { definitions of act and (o) } 

map (actt) (d\ ++^2) 
= { naturality of (+t-) } 

map (act t) d\ +f map (act t) cfe 
= { definition } 

act td\<> act t d2 

where the central step follows from a "free theorem" [Wadler 1989] 
derived from the type of (-H-). 

Equations (3) and (4) together say that the action of any partic- 
ular Transformation is a monoid homomorphism from Diagram 



to itself. This sounds desirable: when the type being acted upon 
has some structure, we want the monoid action to preserve it. From 
now on, we include these among the monoid action laws when the 
type being acted upon is also a Monoid: 

act me — £ (MA3) 

act m (»i 0112) = act mni oactmri2 (MA4) 

It's finally time to stop pretending: so far, a value of type 
Diagram contains not only a (dualized) list of primitives, but also 
cached Envelope and Trace values. When applying a transforma- 
tion to a Diagram, something must be done with these cached 
values as well. An obviously correct but highly unsatisfying ap- 
proach would be to simply throw them away and recompute them 
from the transformed primitives every time. 

However, there is a better way: all that's needed is to define an 
action of Transformation on both Envelope and Trace, subject to 
(MA1)-(MA4) along with 

act t o envelopeP = envelope? o act t (TE) 

act t o traceP = traceP o act t (TT) 

Equations (TE) and (TT) specify that transforming a primitive's 
envelope (or trace) should be the same as first transforming the 
primitive and then finding the envelope (respectively trace) of the 
result. (Intuitively, it would be quite strange if these did not hold; 
we could even take them as the definition of what it means to 
transform a primitive's envelope or trace.) 

instance Action Transformation Envelope where 

instance Action Transformation Trace where 

instance Action Transformation Diagram where 
act? (Diagram (Dualp.¥,e,fr)) 

= Diagram (Dual (map (act t) ps),act t e,act t tr) 

Incidentally, it is not a priori obvious that such instances can 
even be defined — the action of Transformation on Envelope in 
particular is nontrivial and quite interesting. However, it is beyond 
the scope of this paper. 

We must prove that this gives the same result as throwing away 
the cached Envelope and Trace and then recomputing them directly 
from the transformed primitives. The proof for Envelope is shown 
here; the proof for Trace is entirely analogous. 

As established in Variation III, the envelope e stored along with 
primitives ps satisfies the invariant 

e = horn envelopeP ps. 

We must therefore prove that 

act t (horn envelopeP ps) = horn envelopeP (map (act t) ps) , 

or, in point-free form, 

act to horn envelopeP = horn envelopeP o map (act t) . 

Proof. We reason as follows: 

act t o horn envelope P 
= { definition } 

act t o mconcat o map envelopeP 
= { lemma proved below } 

mconcat o map (act t) o map envelopeP 
= { list functor, (TE) } 

mconcat o map envelopeP o map (act t) 
= { definition } 

horn envelopeP o map (act t) □ 




Figure 10. Laying out a line of circles with beside 



It remains only to prove that act t o mconcat = mconcat o 
map (act t). This is where the additional monoid action laws (MA3) 
and (MA4) come in. The proof also requires some standard facts 
about mconcat, which are proved in the Appendix. 

Proof. The proof is by induction on an arbitrary list (call it I) given 
as an argument to act t o mconcat. If / is the empty list, 

act t (mconcat []) 

= { mconcat } 

act t £ 

= { monoid action (MA3) } 
e 

= { mconcat, definition of map } 

mconcat (map (act t) []) 
In the case that l = x:xs, 

act t (mconcat (x:xs)) 
= { mconcat } 

act t (x o mconcat xs) 
= { monoid action (MA4) } 

act t xoact t (mconcat xs) 
= { induction hypothesis } 

act t xo mconcat (map (act t) xs) 
= { mconcat } 

mconcat (act t x : map (act t) xs) 
= { definition of map } 

mconcat (map (act t) (x : xs ) ) □ 

Variation VII: Efficiency via deep embedding 

Despite the efforts of the previous variation, applying transforma- 
tions to diagrams is still not as efficient as it could be. The problem 
is that applying a transformation always requires a full traversal 
of the list of primitives. To see why this is undesirable, imagine a 
scenario where we alternately superimpose a new primitive on a 
diagram, transform the result, add another primitive, transform the 
result, and so on. In fact, this is exactly what happens when using 
beside repeatedly to lay out a line of diagrams, as in the following 
code (whose result is shown in Figure 10): 

unit x :: V2 — unit vector along the positive x-axis 
heat = foldr (beside unit x ) £ 

UneOfCircles n = heat (replicate n circle) 

Fully evaluating UneOfCircles n takes 0(n 2 ) time, because the Mi 
call to beside must map over k primitives, resulting in 1 + 2 + 3 + 

h n total calls to transformP. (Another problem is that it results 

in left-nested calls to (-H-); this is dealt with in the next variation.) 
Can this be improved? 

Consider again the monoid action law 

act (t\ o tj) = act ti o act tj- 

Read from right to left, it says that instead of applying two trans- 
formations (resulting in two traversals of the primitives), one can 



achieve the same effect by first combining the transformations and 
then doing a single traversal. Taking advantage of this requires 
some way to delay evaluation of transformations until the results 
are demanded, and a way to collapse multiple delayed transforma- 
tions before actually applying them. 

A first idea is to store a "pending" transformation along with 
each diagram: 

newtype Diagram = 

Diagram (Dual [Prim], Transformation, Envelope, Trace) 

In order to apply a new transformation to a diagram, simply com- 
bine it with the stored one: 

instance Action Transformation Diagram where 
act f' (Diagram (ps,t,e,tr)) 

= Diagram (ps,t' ot,act / e,actt' tr) 

However, we can no longer automatically derive Semigroup or 
Monoid instances for Diagram — that is to say, we could, but the 
semantics would be wrong! When superimposing two diagrams, 
it does not make sense to combine their pending transformations. 
Instead, the transformations must be applied before combining: 

instance Semigroup Diagram where 

(Diagram {psi,h,ei,tr x ))o (Diagram (ps 2 ,t 2 ,e 2 ,tr 2 )) 
= Diagram (act t x ps l oact t 2 ps 2 , 
e, 

e\ oe 2 , 
tr x otr 2 ) 

So, transformations are delayed somewhat — but only until a call to 
(o), which forces them to be applied. This helps with consecutive 
transformations, but doesn't help at all with the motivating scenario 
from the beginning of this variation, where transformations are 
interleaved with compositions. 

In order to really make a difference, this idea of delaying trans- 
formations must be taken further. Instead of being delayed only 
until the next composition, they must be delayed as long as possi- 
ble, until forced by an observation. This, in turn, forces a radical re- 
design of the Diagram structure. In order to delay interleaved trans- 
formations and compositions, a tree structure is needed — though a 
Diagram will still be a list of primitives from a semantic point of 
view, an actual list of primitives no longer suffices as a concrete 
representation. 

The key to designing an appropriate tree structure is to think 
of the functions that create diagrams as an algebraic signature, 
and construct a data type corresponding to the free algebra over 
this signature [Turner 1985]. Put another way, so far we have a 
shallow embedding of a domain-specific language for constructing 
diagrams, where the operations are carried out immediately on 
semantic values, but we need a deep embedding, where operations 
are first reified into an abstract syntax tree and interpreted later. 

More concretely, here are the functions we've seen so far with a 
result type of Diagram: 

prim:: Prim — > Diagram 
£ :: Diagram 

(o) :: Diagram — > Diagram —¥ Diagram 

act "Transformation — > Diagram — ► Diagram 

We simply make each of these functions into a data constructor, 
remembering to also cache the envelope and trace at every node 
corresponding to (o): 

data Diagram 
= Prim Prim 
| Empty 

| Compose (Envelope, Trace) Diagram Diagram 
| Act Transformation Diagram 



There are a few accompanying functions and instances to define. 
First, to extract the Envelope of a Diagram, just do the obvious 
thing for each constructor (extracting the Trace is analogous): 



envelope : 
envelope 
envelope 
envelope 
envelope 



: Diagram — > 
(Prim p) 
Empty 

(Compose (e,_) 
(Act t d) 



Envelope 

= envelopeP p 
= £ 

-) = e 

= act t (envelope d) 



By this point, there is certainly no way to automatically derive 
Semigroup and Monoid instances for Diagram, but writing them 
manually is not complicated. Empty is explicitly treated as the 
identity element, and composition is delayed with the Compose 
constructor, extracting the envelope and trace of each subdiagram 
and caching their compositions: 

instance Semigroup Diagram where 
Empty od = d 
do Empty = d 

d\od 2 

= Compose 

(envelope d\ o envelope d 2 
, trace d\ o trace d 2 
) 

d\ d 2 

instance Monoid Diagram where 
e = Empty 

The particularly attentive reader may have noticed something 
strange about this Semigroup instance: (o) is not associative! 
d\ o (d 2 odi) and (d\ od 2 ) od 3 are not equal, since they result 
in trees of two different shapes. However, intuitively it seems that 
d\ o (d 2 odi,) and (d x od 2 )od^ are still "morally" the same, that is, 
they are two representations of "the same" diagram. We can formal- 
ize this idea by considering Diagra m as a quotient type, using some 
equivalence relation other than structural equality. In particular, as- 
sociativity does hold if we consider two diagrams d\ and d 2 equiv- 
alent whenever unD d x = unD d 2 , where unD :: Diagram — > [ Prim ] 
"compiles" a Diagram into a flat list of primitives. The proof is 
omitted; given the definition of unD below, it is straightforward 
and unenlightening. 

The action of Transformation on the new version of Diagram 
can be defined as follows: 

instance Action Transformation Diagram where 
act t Empty = Empty 
act t (Act ? d) = Act (tot') d 
act td — Act t d 

Although the monoid action laws (MAI) and (MA2) hold by defini- 
tion, (MA3) and (MA4) again hold only up to semantic equivalence 
(the proof is similarly straightforward). 

Finally, we define unD, which "compiles" a Diagram into a 
flat list of Prims. A simple first attempt is just an interpreter that 
replaces each constructor by the operation it represents: 



unD :: Diagram — > 
unD (Prim p) 
unD Empty 
unD (Compose. 
unD (Act t d) 



d\ d 2 ) 



[Prim] 

= [P] 
= e 

- unD d 2 o unD d\ 

- act t (unD d) 



This seems obviously correct, but brings us back exactly where 
we started: the whole point of the new tree-like Diagram type 
was to improve efficiency, but so far we have only succeeded in 
pushing work around! The benefit of having a deep embedding is 
that we can do better than a simple interpreter, by doing some sort 
of nontrivial analysis of the expression trees. 



In this particular case, all we need to do is pass along an extra 
parameter accumulating the "current transformation" as we recurse 
down the tree. Instead of immediately applying each transformation 
as it is encountered, we simply accumulate transformations as we 
recurse and apply them when reaching the leaves. Each primitive is 
processed exactly once. 

unD' :: Diagram -¥ [Prim] 
unD' — go e where 

go :: Transformation — > Diagram — > [Prim] 

got (Primp) =[acttp] 

go _ Empty = £ 

got (Compose _d\ di) = go td2<>go td\ 

go t (Act / d) = go (tot 1 ) d 

Of course, we ought to prove that unD and unD' yield identical 
results — as it turns out, the proof makes use of all four monoid 
action laws. To get the induction to go through requires proving the 
stronger result that for all transformations t and diagrams d, 

act t (unD d) —gotd. 

From this it will follow, by (MAI), that 

unD d = act £ (unD d) = go £ d = unD' d. 

Proof. By induction on d. 

• lfd= Prim p, then act t (unD (Primp)) = actt [p] = [acttp] = 
go t (Prim p). 

• If d = Empty, then actt (unD Empty) = actt£ = £ = got Empty, 
where the central equality is (MA3). 

• If d = Compose c d\ cfc, then 

act t (unD (Compose c d\ d<ij) 
= { definition } 

act t (unD d2 o unD d\ ) 
= { monoid action (MA4) } 

act t (unD di) o act t (unD d\ ) 
= { induction hypothesis } 

gotdi<>got d\ 
= { definition } 

go t (Compose c d\ dj) 

• Finally, if d = Act t' d', then 

actt (unD (Act f 7 d')) 
= { definition } 

actt (actt' (unD d')) 
= { monoid action (MA2) } 

act (tot 1 ) (unDd!) 
— { induction hypothesis } 

go (tot 1 ) d' 
= { definition } 

go t (Act t 1 d') D 

Variation VIII: Difference lists 

Actually, unD 1 still suffers from another performance problem 
hinted at in the previous variation. A right-nested expression like 
d\ o (d2<> (d^od^)) still takes quadratic time to compile, because 
it results in left-nested calls to (-H-). This can be solved using dif- 
ference lists [Hughes 1986]: the idea is to represent a list xs :: [a] 
using the function (xs44-) :: [a] — > [a]. Appending two lists is then 
accomplished by composing their functional representations. The 



"trick" is that left-nested function composition ultimately results in 
reassociated (right-nested) appends: 

(((xH+) ° Cys+t-)) o (zs-H-)) [] =xs-H-(ys-H-(zs +*-[])). 

In fact, difference lists arise from viewing 

(-H-) ::[*]-► ([a] -►[*]) 
itself as a monoid homomorphism, from the list monoid to the 
monoid of endomorphisms on [a]. (HI) states that (44-) £ = £, 
which expands to (-H-) [] = id, that is, [] 44- xs = xs, which is true 
by definition. (H2) states that (44-) (xsoys) = (-H-) xso(-H-) ys, 
which can be rewritten as 

((xs+\-ys)-\+) = (xs+h) o (ys+h). 

In this form, it expresses that function composition is the correct 
implementation of append for difference lists. Expand it a bit fur- 
ther by applying both sides to an arbitrary argument zs, 

(xs 44- ys) 44- zs = xs 44- (ys 44- zs) 

and it resolves itself into the familiar associativity of (44- ). 
Here, then, is a yet further improved variant of unD: 

unD" :: Diagram — > [Prim] 

unD" d = appEndo (go £ d) [ ] where 

go :: Transformation — > Diagram — > Endo [Prim] 

got (Primp) = Endo ((act tp)\) 

go _ Empty =£ 

go t (Compose _c/i ^2) = go t d2<> go t d\ 

got(Actt'd) =go(tot')d 

Variation IX: Generic monoidal trees 

Despite appearances, there is nothing really specific to diagrams 
about the structure of the Diagram data type. There is one construc- 
tor for "leaves", two constructors representing a monoid structure, 
and one representing monoid actions. This suggests generalizing to 
a polymorphic type of "monoidal trees": 

data MTree d u I 
= Leaf u I 
I Empty 

I Compose u (MTree dul) (MTree dul) 
j Act d (MTree dul) 

d represents a "downwards-traveling" monoid, which acts on the 
structure and accumulates along paths from the root, u represents 
an "upwards-traveling" monoid, which originates in the leaves and 
is cached at internal nodes. / represents the primitive data which is 
stored in the leaves. 

We can now redefine Diagram in terms of MTree: 

type Diagram 

= MTree Transformation (Envelope, Trace) Prim 

prim p — Leaf (envelopeP p, traceP p) p 

There are two main differences between MTree and Diagram. 
First, the pair of monoids, Envelope and Trace, have been replaced 
by a single u parameter — but since a pair of monoids is again a 
monoid, this is really not a big difference after all. All that is needed 
is an instance for monoid actions on pairs: 

instance (Action m a, Action m b) 
=> Action m (a, b) where 

act m (a, b) = (act ma, act mb) 

The proof of the monoid action laws for this instance is left as a 
straightforward exercise. 

A second, bigger difference is that the Leaf constructor actually 
stores a value of type u along with the value of type /, whereas 



the Prim constructor of Diagram stored only a Prim. Diagram 
could get away with this because the specific functions envelopeP 
and traceP were available to compute the Envelope and Trace for 
a Prim when needed. In the general case, some function of type 
(I — > u) would have to be explicitly provided to MTree operations 
— instead, it is cleaner and easier to cache the result of such a 
function at the time a Leaf node is created. 

Extracting the u value from an MTree is thus straightforward. 
This generalizes both envelope and trace: 

getU :: (Action d u, Monoid u) => MTree dul^f u 
getU (Leaf u _) = u 

getU Empty = e 

getU (Compose u ) = u 

getU (Act d t) = act d (getU t) 

envelope— fst o getU 
trace = sndo getU 

The Semigroup and Action instances are straightforward gen- 
eralizations of the instances from Variation VII. 

instance (Action d u, Monoid u) 
=> Semigroup (MTree dul) where 
Emptyof = t 
to Empty = t 

h ot 2 ~ Compose (getU t\OgetU t-i) t\ ?2 
instance Semigroup d => Action d (MTree dul) where 
act _ Empty = Empty 
actd (Act d! i) = Act (dod')t 
actdt = Act d t 

In place of unD, we define a generic fold for MTree, returning 
not a list but an arbitrary monoid. There's really not much differ- 
ence between returning an arbitrary monoid and a free one (i.e. 
a list), but it's worth pointing out that the idea of "difference lists" 
generalizes to arbitrary "difference monoids": (o) itself is a monoid 
homomorphism. 

foldMTree :: (Monoid d, Monoid r, Action d r) 

=> (I r) -» MTree dul^r 
foldMTree leaf t = appEndo (go £ t) £ where 

go d (Leaf _ /) = Endo (act d (leaf /)o) 

go _ Empty = e 

go d (Compose _ t\ tj) = go d t\ o go d t2 

go d (Act d' t) = go (dod')t 

unDv. Diagram — \ [Prim] 

unD = getDualo foldMTree (Dual o (:[])) 

Again, associativity of (o) and the monoid action laws only hold 
up to semantic equivalence, defined in terms of foldMTree. 

Variation X: Attributes and product actions 

So far, there's been no mention of fill color, stroke color, trans- 
parency, or other similar attributes we might expect diagrams to 
possess. Suppose there is a type Style representing collections of 
attributes. For example, {Fill Purple, Stroke Red} :: Style might in- 
dicate a diagram drawn in red and filled with purple. Style is then 
an instance of Monoid, with e corresponding to the Style contain- 
ing no attributes, and (o) corresponding to right-biased union. For 
example, 

{Fill Purple, Stroke Red}o{Stroke Green, Alpha 0.3} 

= {Fill Purple, Stroke Green, Alpha 0.3} 

where Stroke Green overrides Stroke Red. We would also expect 
to have a function 

applyStyle :: Style — > Diagram — > Diagram 



for applying a Style to a Diagram. Of course, this sounds a lot like 
a monoid action! However, it is not so obvious how to implement a 
new monoid action on Diagram. The fact that Transformation has 
an action on Diagram is encoded into its definition, since the first 
parameter of MTree is a "downwards" monoid with an action on 
the structure: 

type Diagram 

— MTree Transformation (Envelope, Trace) Prim 

Can we simply replace Transformation with the product monoid 
(Transformation, Style)? Instances for Action Style Envelope and 
Action Style Trace need to be defined, but these can just be trivial, 
since styles presumably have no effect on envelopes or traces: 

instance Action Style Envelope where 

act _ = id 

In fact, the only other thing missing is an Action instance defining 
the action of a product monoid. One obvious instance is: 

instance (Action m\ a, Action ni2 a) 
=> Action (m\,m2) a where 
act (m\,ni2) = act m\ o act ni2 

though it's not immediately clear whether this satisfies the monoid 
action laws. It turns out that (MAI), (MA3), and (MA4) do hold 
and are left as exercises. However, (MA2) is a bit more interesting. 
It states that we should have 

act ((mn,m2\)o(m\2,m22)) 

— act (m\\,m2\) oact (mi2,'«22). 
Beginning with the left-hand side, 

act ((mii,m 2 i)o(m 12 ,m22)) 
= { product monoid } 

act (m\\Om\2,m2\ om 2 2) 
= { proposed definition of act for pairs } 

act (m\i om\2) oact (m.21 om.22) 
= { m\ I a, m2 / a (MA2) } 

act nii\oactm\20 act m.21 0 act ™22 
But the right-hand side yields 

act (m\i,m2i)oact (m\2,m22) 
= { proposed definition of act } 
act mn oactm2i o act mi2 oact 1^22 

In general, these will be equal only when act m^o act W21 = 
act wi2i o act mi2 — and since these are all arbitrary elements of the 
types mi and m2, (MA2) will hold precisely when the actions of 
m\ and m2 commute. Intuitively, the problem is that the product of 
two monoids represents their "parallel composition", but defining 
the action of a pair requires arbitrarily picking one of the two 
possible orders for the elements to act. The monoid action laws hold 
precisely when this arbitrary choice of order makes no difference. 

Ultimately, if the action of Transformation on Diagram com- 
mutes with that of Style — which seems reasonable — then adding 
attributes to diagrams essentially boils down to defining 

type Diagram = MTree (Transformation, Style) 
(Envelope, Trace) 
Prim 

Coda 

Monoid homomorphisms have been studied extensively in the pro- 
gram derivation community, under the slightly more general frame- 
work of list homomorphisms [Bird 1987]. Much of the presentation 



here involving monoid homomorphisms can be seen as a particular 
instantiation of that work. 

There is much more that can be said about monoids as they 
relate to library design. There is an intimate connection between 
monoids and Applicative functors, which indeed are also known 
as monoidal functors. Parallel to Semigroup is a variant of 
Applicative lacking the pure method, which also deserves more 
attention. Monads are (infamously) monoidal in a different sense. 
More fundamentally, categories are "monoids with types". 

Beyond monoids, the larger point is that library design should 
be driven by elegant underlying mathematical structures, and espe- 
cially by homomorphisms [Elliott 2009]. 
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Appendix 

Given the definition mconcat =foldr (o) £, we compute mconcat [ ] = 
foldr (o) £ [ ] = £, and 

mconcat (x:xs) 
— foldr (o) e (x : xs) 
— xo foldr (o) £ xs 
= x o mconcat xs. 

These facts are referenced in proof justification steps by the hint 
mconcat. 

Next, recall the definition of horn, namely 

horn:: Monoid m =>■ (a — > m) — > ([a] -¥ m) 
homf = mconcat o mapf 

We first note that 

homf (x : xs) 
= { definition of horn and map } 

mconcat (f x : mapf xs) 
= { mconcat } 

f xo mconcat (mapf xs) 
— { definition of horn } 

f xohomf xs 

We now prove that homf is a monoid homomorphism for all/. 

Proof. First, horn f [ ] = (mconcat o map f) [ ] = mconcat [ ] = £ 
(HI). 

Second, we show (H2), namely, 

horn f (xs -H- ys) = homf xs o homf ys, 
by induction on xs. 



• If xs= [], we have homf ([] +\-ys) = homf ys = eohomf ys = 
horn f []ohomf ys. 

• Next, suppose xs =x:xs l : 

homf ((x : xs 1 ) +\-ys) 

{ definition of (+f) } 
= homf (x : (xs 1 +\-ys)) 

{ horn of (:), proved above } 
= / xohomf (xs' +f ys) 

{ induction hypothesis } 
=f xo homf xs' o homf ys 

{ associativity of (o) and horn of (:) } 
= (homf (x:xs J ))ohomf ys 

As a corollary, mconcat (xs-\+ys) = mconcat xs -H- mconcat ys, 
since horn id = mconcat o map id = mconcat. 



